As is known, and referring now to FIG. 1, a rights management (RM) and enforcement system is highly desirable in connection with digital content 12 such as digital audio, digital video, digital text, digital data, digital multimedia, etc., where such digital content 12 is to be distributed to users. Upon being received by the user, such user renders or ‘plays’ the digital content with the aid of an appropriate rendering device such as a media player on a personal computer 14, a portable playback device or the like.
Typically, a content owner distributing such digital content 12 wishes to restrict what the user can do with such distributed digital content 12. For example, the content owner may wish to restrict the user from copying and re-distributing such content 12 to a second user, or may wish to allow distributed digital content 12 to be played only a limited number of times, only for a certain total time, only on a certain type of machine, only on a certain type of media player, only by a certain type of user, etc.
However, after distribution has occurred, such content owner has very little if any control over the digital content 12. An RM system 10, then, allows the controlled rendering or playing of arbitrary forms of digital content 12, where such control is flexible and definable by the content owner of such digital content. Typically, content 12 is distributed to the user in the form of a package 13 by way of any appropriate distribution channel. The digital content package 13 as distributed may include the digital content 12 encrypted with a symmetric encryption/decryption key (KD), (i.e., (KD(CONTENT))), as well as other information identifying the content, how to acquire a license for such content, etc.
The trust-based RM system 10 allows an owner of digital content 12 to specify rules that must be satisfied before such digital content 12 is allowed to be rendered. Such rules can include the aforementioned requirements and/or others, and may be embodied within a digital license 16 that the user/user's computing device 14 (hereinafter, such terms are interchangeable unless circumstances require otherwise) must obtain from the content owner or an agent thereof, or such rules may already be attached to the content 12. Such license 16 may for example include the decryption key (KD) for decrypting the digital content 12, perhaps encrypted according to another key decryptable by the user's computing device or other playback device.
The content owner for a piece of digital content 12 would prefer not to distribute the content 12 to the user unless such owner can trust that the user will abide by the rules specified by such content owner in the license 16 or elsewhere. Preferably, then, the user's computing device 14 or other playback device is provided with a trusted component or mechanism 18 that will not render the digital content 12 except according to such rules.
The trusted component 18 typically has an evaluator 20 that reviews the rules, and determines based on the reviewed rules whether the requesting user has the right to render the requested digital content 12 in the manner sought, among other things. As should be understood, the evaluator 20 is trusted in the DRM system 10 to carry out the wishes of the owner of the digital content 12 according to the rules, and the user should not be able to easily alter such trusted component 18 and/or the evaluator 20 for any purpose, nefarious or otherwise.
As should be understood, the rules for rendering the content 12 can specify whether the user has rights to so render based on any of several factors, including who the user is, where the user is located, what type of computing device 14 or other playback device the user is using, what rendering application is calling the RM system 10, the date, the time, etc. In addition, the rules may limit rendering to a pre-determined number of plays, or pre-determined play time, for example.
The rules may be specified according to any appropriate language and syntax. For example, the language may simply specify attributes and values that must be satisfied (DATE must be later than X, e.g.), or may require the performance of functions according to a specified script (IF DATE greater than X, THEN DO . . . , e.g.).
Upon the evaluator 20 determining that the user satisfies the rules, the digital content 12 can then be rendered. In particular, to render the content 12, the decryption key (KD) is obtained from a pre-defined source and is applied to (KD(CONTENT)) from the content package 13 to result in the actual content 12, and the actual content 12 is then in fact rendered.
In an RM system 10, content 12 is packaged for use by a user by encrypting such content 12 and associating a set of rules with the content 12, whereby the encrypted content 12 can be decrypted and rendered only in accordance with the rules. Because the encrypted content 12 can only be decrypted and rendered in accordance with the rules, then, the content 12 may be freely distributed.
As may be appreciated, rendering of the content 12 may be performed in multiple parts of the computing device 14. In particular, it is typical that preliminary rendering of the content 12 occurs in a processor 22 of the computing device 14 upon which the trusted component 18 is instantiated, and that final rendering of the content 12 occurs in a peripheral 24 of the computing device 14. For example, such preliminary rendering in the processor 22 may include the aforementioned decrypting, an evaluation of the processing necessary to render the content 12, a division of the content 12 into components thereof, and forwarding of each component of the content 12 to an appropriate location such as the aforementioned peripheral 24 for further processing and the aforementioned final rendering. As should be evident, such peripheral 24 and corresponding final rendering may be any appropriate peripheral 24 and final rendering. For example, for a video component of content 12, the peripheral 24 may be a video processor or graphics processing unit where the video component is employed to render screen pixels, and for an audio component of content 12, the peripheral 24 may be a sound processor or audio processing unit where the audio component is employed to generate speaker input. Note too that the content 12 may be protected going to a peripheral 24 such as a storage device or a network card, or may be incoming data from an external source such as a microphone, a camera, a remote location, etc. Typically, each peripheral 24 is coupled to the processor 22 by way of a path 26 such as a common bus. For example, the bus may be a PCI (Peripheral Component Interconnect) bus or another bus.
Preferably, each component of the content 12 is transmitted over the path 26 in an encrypted form from the source processor 22 to the destination peripheral 24. Thus, the component cannot be copied in an unencrypted digital form from the path 26. Such encrypted form may be the original encryption of the content 12, or more typically is an encryption of the component after the content 12 has been decrypted and preliminarily rendered by the processor 22.
As was stated above, the trusted component 18 on the processor 22 exists to ensure that the content 12 is rendered only in accordance with the rules specified by the content owner in the corresponding license 16 or elsewhere. However, the ability of the trusted component 18 to perform such function decreases as the content 12 moves from the processor 22 to a peripheral 24, especially when the peripheral has processing abilities of its own. That is, while the trusted component 18 as instantiated on the processor 22 can more tightly control how and whether such processor 22 handles the protected content 12, such trusted component 18 cannot as tightly control how and whether the peripheral 24 likewise handles the protected content 12, especially when the peripheral 24 has its own processor or the like and such processor is not under the control of the processor 22. Accordingly, the trusted component 18 should not allow the processor 22 to transmit content 12 to such a peripheral 24 over the path 26 therebetween unless the peripheral 24 can be established as trustworthy in that the peripheral can be trusted to handle content 12 received thereby only in accordance with the aforementioned rules.
Accordingly, a need exists for an architecture and method that define a trusted path 26 by which content 12 can be transmitted from a processor 22 to a peripheral 24 in a computing device 14. In particular, a need exists for a method and architecture that defines how to establish that a peripheral 24 in a computing device 14 is trustworthy.